4.2.4 ガイド:LeSS Huge の組織
#LeSS本
必ずしもスケールするために組織構造の追加は必須ではない
組織構造の追加は狭い責任範囲を引き起こし、組織の機能不全や政治の温床になりやすくなる
典型的な LeSS Huge の組織図
LeSS Huge の構造は LeSS の構造の上に作られている。プロジェクト/プログラム組織(または PMO)をが存在しない(スクラムや LeSS の導入でこれらの組織はなくなる)
https://scrapbox.io/files/649ba76dd64988001cec4dab.png
LeSS の組織と異なる部分
拠点内のチーム
LeSS Huge の導入は、複数拠点になることが多い
組織は通常、拠点内で完結するライン組織を作ることを好む。これにより、マネージャーは簡単に現地現物を実践し、実際にチームが改善するのを手助けできる
要求エリアを組織構造と同じにすることは、変更が難しくなるため避けるべき
プロダクトオーナーチーム
概念的には LeSS 構造と同じ
プロダクトオーナーチームには、全てのエリアのプロダクトオーナーが含まれるため、より大きなチームとなる
巨大な LeSS Huge グループでは、プロダクトオーナーチームには、要求エリア内にサブチームがある
Undone 部門
概念的には LeSS 構造と同じ
LeSS Huge のグループでは Undone 部門が大きくなる傾向があり、取り除くにはより長い時間が掛かる
巨大な LeSS Huge グループの Undone 部門には、昔ながらの独自のプロジェクトマネジメント手法を行う追加された組織構造が存在することもある
サポート部門
チームの開発環境をサポートする部門
LeSS では、チームは別のグループを助けること無くお互いをサポートする
LeSS Huge では、作業が大量になるためサポートを一元化する
この部門はできるだけ小さくする
🙅‍♀️「このやり方でやってください」
🙆‍♀️「何か助けられることはありますか?
チームから責任を奪い、結局はチームのサポートでなく、力を得ながら成長し続ける管理組織にならないように注意
構成管理支援は、サポートグループが統制グループになってしまうよくある例
サポートチームが全てのビルドスクリプトを作成することで、チームが「ビルド完了」で何が起きるのか把握できなくなる
これによりビルドをより良くすることに対して無力だと感じ始める
構成管理支援グループは、本来はチームが改善するのを助け、ビルドについて教育し、オーナーになるのではなく良いビルド方法を教える専門化でいるべき
チームメンバーとペアを組んだり、他の作業を観察したりして、協力して改善する方法を一緒に探求する
能力開発とコーチング
積極的なコーチングなしに LeSS の導入を成功した事例はない
ソフトウェアは人によって作られる。人を改善することはプロダクト改善につながる。
LeSS Huge の組織には、継続的改善に欠かせない専門のトレーニングとコーチングの部門がある
能力開発とコーチング部門が重点を置く 3 点
観察(現地現物)
トレーニング
コーチング
能力開発とコーチング部門に求められる人: 積極的に現地現物と人々の作業の観察を行う、スキルの高い実践的なエキスパート
トレーニングの必要性を発見するためにペアになってチームと働く
人は、存在を知らないトレーニングや、自分自身の能力が低いと気づかないスキルのトレーニングを求めることができない
コーチングは、チームの改善を支援する最も効果的な方法
コーチ達はチーム共に(またはチームの中で)働く
コーチ達はコーチング手法を活用する(e.g. 観察する、ペアを組む、シャドウコーチングする、質問をする)
コーチ達は観察、フィードバック、アイデア、チームの改善方法に関する例を示す
コーチングのレベル(全てのレベルが重要)
組織
チームとプロダクトオーナー
技術